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ABSTRACT 

A model of the interface design process is proposed 
that makes use of two interdependent levels of cognitive analysis: 
the study of the criterion task through an analysis of expert/novice 
differences and the evaluation of the working user interface design 
through the application of a practical interface analysis methodology 
(GOMS model). This dual analysis is reviewed in the context of 
HYDRIVE, a video-based intelligent tutoring system designed to 
facilitate the development of troubleshooting skills for technicians 
working on aircraft hydraulics systems. The initial cognitive task 
analysis enabled the identification of critical troubleshooting 
skills and troubleshooting procedures. It is found that, even with an 
in-depth initial cognitive task, the GOMS interface analysis resulted 
in significant and beneficial design changes. Two figures illustrate 
the discussion. (SLD) 
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ABSTRACT 

We propose a model of the interface design process that makes use of two interdependent levels of cognitive analysis: 
1) the study of the criterion task through an analysis of expert/novice differences and; 2) the evaluation of die working 
user interface design through the application of a practical interface analysis methodology (GOMS model). We review 
this dual analysis in the context of HYDRIVE, a video-disc based intelligent tutoring system designed to facilitate the 
development of troubleshooting skills for aircraft hydraulics systems. The initial cognitive task analysis enabled die 
identification of critical troubleshooting skills and troubleshooting procedures. We find, though, that even with an in-depth 
initial cognitive task analysis, the GOMS interface analysis resulted in significant and beneficial design changes. 
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INTRODUCTION 

Intelligent tutoring systems necessarily rely on an abstracted representation of a target task. Even in a reasonably faithful 
simulation environment, there are significant distinctions between a target task and its representation in a tutoring system. 
Good system design ensures that the most critical and cognitively demanding features of the target task are 
well-represented by the system. Features of a target task which are not as determinant of performance may be ignored 
in a tutoring environment. So, for example, in the domain of mechanical troubleshooting, the ability to use a screwdriver 
may be universally mastered, and thus not related to performance skill nor a potential object for consideration in a 
tutoring environment. 

Conceiving of the development of tutoring environments as the deliberate selection of critical cognitive features impli«> 
a two-tiered level of cognitive task analysis. First, the target task must be analyzed to understand origins of task 
difficulty and individual differences in performance. Such analysis informs decisions about the focus of the tutoring 
system. With the focus determined, a key question is whether the system's interface simulates and supports performance 
of critical actions in a direct and seamless fashion. The cognitive analysis of performance using the tutoring system's 
interface represents the second level of cognitive task analysis. 

The purpose of this paper is to describe the development of an interface for HYDRIVIi a PC/video-disc based intelligent 
tutoring system designed to help U.S. Air Force fighter aircraft maintenance personnel, specifically F-15 hydraulics 
technicians, acquire a powerful and gcncralizable set of troubleshooting skills which they can apply in fulfilling their day 
to day maintenance responsibilities, trough the example of HY DRIVE, we discuss the application of a two-tiered 
cognitive task analysis to design of an interface that supports die important aspects of hydraulic system troubleshooting. 

WHAT THE HYDRAULICS TECHNICIAN DOES 

The F-15 hydraulics technician maintains the aircraft's hydraulic power system, which generates hydraulic power, and 
all other F-15 systems which use hydraulic power: the flight controls, the landing gear, die canopy (transparent bubble 
though which the pilot enters and exits the aircraft), the jet fuel starter system for the aircraft engines ;uid the aerial 
refueling system. The hydraulics technician is responsible for diagnosing and fixing aircraft problems while the F-15 
is still on the flightline, the place from which the aircraft taxis to takeoff and returns after landing. The technician is 
present when the pilot checks out the aircraft just before takeoff and is the first person to be briefed by the pilot 
immediately after landing. The priority in flightline maintenance is to find the faulty component as quickly as possible 



and replace it. The cost of any given flightline maintenance job is measured largely in terms of how long it takes: the 
more time the technician requires to troubleshoot the problem correctly, the longer the aircraft is not able to fly and the 
higher the cost. During troubleshooting, the technician has access to technical materials, including step-by-step fault 
isolation guides, descriptions of general systems and principles of opei-tion, schematic diagrams and step-by-step 
maintenance procedure guides. Diagnosing and fixing a defective component is a maintenance shop job and not die 
responsibility of the flightline technician. 

Generally speaking, hydraulic systems consist of a limited number of physically accessible components that have 
restricted sets of well-defined functions. Not only is it possible, then, for hydraulics technicians to "know" die systems 
they have to deal with (where "knowing" means having some idea, or mental model, of how die components in a given 
system work together to accomplish the system's task, like opening or closing the canopy), but it is also possible to get 
a great deal of information from observing actual aircraft operation. Failures of die canopy to open or the rudders to 
move under emergency conditions provide immediate and important clues about the cause of the failure. The technician 
is likely to run a system through various conditions to obtain a better sense of when and how failures occur. The 
relati vely transparent nature of the hydraulic system can be contrasted with digital circuitry in which die mapping between 
component function and system operation is much less obvious. 

The hydraulics job, like most flightline jobs, requires social problem-solving. 'Hie interdependence of avionic, electrical, 
hydiaulic and mechanical systems means that technicians from different specialties need to work togedier to find where 
die failure is located. Hie hydraulics technician frequently will ask an electrician to test wiring in order to determine if 
some part of a specific hydraulics system is functional. Thus, die hydraulics technician needs to understand the relation 
between different aircraft power systems and to obtain and use information from other individuals to make judgments 
about die hydraulics system. 

The team approach, however, can sometimes be- detrimental to die learning of critical skills. A great deal of die 
hydraulics maintenance job is physically time-consuming. I ; or example, ii may take eight hours to replace a valve not 
because it was so difficult to figure out that the valve was defective, but rather because die valve is wedged under several 
odier components which, in turn, lie under an exterior aircraft panel secured widi 240 bolts. In flightline maintenance, 
a division of labor can occur in which some personnel routinely take on die cognitive tasks while other, less-experienced 
personPil take on die physical tasks. 11ms it is possible for a technician to have several years of experience widioul ever 
having developed necessary troubleshooting skills. 



WHY AN INTELLIGENT TUTORING SYSTEM? 

Justification for developing an intelligent tutoring system in this domain is provided by Means and Gott [4]. They point 
out that the increasing complexity of military equipment systems has resulted in the automation of many routine 
maintenance tasks. This automation has not only not produced the diagnostic successes hoped for, but has also had the 
unwelcome effect of depriving technicians (up to 25% of whom may be new to the job) of important hands-on learning 
opportunities. Formal training, which is still oriented toward either theory or rote procedure, provides little relevant 
troubleshooting practice. In the field, the priority is to keep systems operational. If automated or routine tests fail to 
diagnose a problem, expert problem solvers, frequently civilians, step in, thereby limiting opportunities for experience 
with nonroutine faults. 

Intelligent tutoring systems help produce better job performance by providing a full range of domain problems (from tlv 
routine to the exotic) presented in a simulated context of on-the-job conditions and sequenced to match the current 
proficiency of the student. Working through an entire problem set not only provides the student with much greater 
exposure to practical troubleshooting, but it also allows learning in an environment that minimizes the unimportant and 
physically tedious parts of the job (eg., unscrewing bolts) and emphasizes the cognitively challenging aspects. Knowledge 
acquired in this way can be more easily transferred into the actual job situation because of similarities between learning 
and working environments and because the equipment system itself can be presented in a way that stresses functional 
characteristics most salient to effective troubleshooting. In addition, learning can take place without reliance on actual 
equipment systems and without the associate! safety and equipment availability concerns. 

LEVEL 1 COGNITIVE TASK ANALYSIS - WHAT IS THE TECHNICIAN'S TASK? 

The precondition to starting work on HYDRIVF/s design, indeed the precondition for many intelligent tutoring systems, 
was the completion of a cognitive analysis of the target task, namely hydraulics troubleshooting. A cognitive task analysis 
attempts to provide an understanding of how pv*,ple at different levels of expertise gather the information necessary to 
perform a particular task, how Lhey process that information and how they deploy it. Hie analysis was done in three 
parts. 'Hie first phase consisted of orientation visits to Air Force base maintenance sites. The second phase was a data 
collection effort using an analytic methodology known as PARI (Precursor, Action, Result, /nterpretation) analysis, which 
was developed in the Basic Job Skills Program [4,5]. Working with a set of twelve problems which had been generated 
by experts, each of approximately twenty technicians, ranging from novice to expert, used the PARI structure to generate 
solutions to at least two of the problems. In the last phase of the task analysis, experts provided follow-up advice and 
feedback. 



An Example of Expert Troubleshooting 

Presented below is an example PARI interaction of an expert troubleshooter. The PARI is annotated with interpretations 
of actions within a cognitive framework. The term PARI derives from the steps of the cognitive task analysis, in which 
P stands for the precursor or working hypothesis, A is the action taken to test that hypothesis, R is the observed result 
of the action and I represents the inteipretation drawn from that result. The interpretation often forms the basis for a new 
working hypothesis (next precursor). 



Initially, the expert is given a fault description and asked to represent the candidate problem space with a block diagram. 
Figure 1 is a schematized version of the subject matter expert's (SME) initial representation of the fault description "Prior 
to taxi, the aircraft had no rudder deflection." This problem was designed so that the cause of the fault was due to the 
breaking or shearing of a mechanical linkage (the splitter or rudder breakout assembly) that controls the operation of both 
rudders. 

Block Diagram 

Fault Descriptio n PI \*R To TAX* AiJt cAAF T J/ AD a/o AOtSA 



**»*»**»»»***» *»*****»»»»»»»* 




»»**»** 




Figure 1. SME Block Diagram 



Step 1 

P: Check for hydraulic power (all flight controls receive hydraulic power to actuators through circuits on reservoir) 
A: Check for Circuit A or B lights in cockpit if pilot has not already done so 
R: No lights in cockpit 

I: Hydraulic pressure is normal according to indicators in cockpit. 



In this first step, the SME wants to ascertain the general status of the hydraulic system. Finding no warning lights in 
the cockpit indicating faulty hydraulic pressure, the SME concludes that the problem is not due to general hydraulic 
failure. 

Step 2 

P: Verify problem. Check electrical and hydraulic in dynamic test. Want to make all relevant checks there with pilot 
present and engines running. 

A: Put Anti-Skid on (to check /light controls through stick). Cycl?. flight controls with stick. 
R: All flight control surfaces move except both rudders. 

I: Hydraulic power is getting to the flight control system; it is eliminated as a possible cause. Rudder hydraulic 
servoactuators are eliminated due to infrequency of both failing simultaneously. The control stick is eliminated as w 
possible cause since it would havt to have no effect on any of ihe flight controls in order to become suspect. 

In step 2, the SME performs a dynamic test of the flight control system to determine the functionality of different 
components within the system. This test requires that the technician manipulate the system through controls in the 
cockpit and observe the functioning of flight control surfaces on the exterior of the aircraft. Proper functioning of systems 
that have components in common with the rudder system leads to the inference that the common components are not 
faulty. This dynamic test has isv>lated the problem to a set of components that are associated only with rudder control. 

Step 3 

P: Check pedals to see if they are rigged properly (pedals are controlling input to rudders). Check Aileron Rudder 
Interconnect for proper mechanical function. 

A: Put mule on. (Mule is hydraulic power source for aircraft when engines are shut down). Set Anti-Skid switch to off 
(to control rudders through pedals). Move rudder pedals. Check mechanical linkage from rudder pedals to Aileron 
Rudder interconnect. Check mechanical linkage from Aileron Rudder Interconnect to splitter. 
R: All linkages are moving. 

I: All linkage from cockpit to splitter (not including splitter) is OK Aileron Rudder Interconnect is OK since the linkage 
which goes to it and exits it is working properly. 

In Step 3, cockpit controls (the rudder pedals) are being manipulated to determine movement of mechanical linkages 
within th<; rudder system. 'Hie technician then must check movement of mechanical linkages in the fuselage of the 
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aircraft. This requires the opening of doors on the fuselage to allow observation of the linkages. The SME finds that 
all linkages up to the Aileron Rudder Interconnect are operational. 

Step 4 

P: Check splitter in dynamic test for conclusive (more than visual check) evidence of fault in splitter. 

A: With another person working pedals, check in Bay 5 for movement of two cables, each leaving Rudder Breakout 

Assembly and going to a rudder actuator. 

R; No movement. 

1: Splitter is faulty. Call mechanical technician to replace shear bolt on splitter. Problem solved. 

In Step 4, the SME continues to trace the path of mechanical linkages, with cockpit control from the rudder pedals. The 
SME finds that there is no mechanical movement as output from the Rudder Breakout Assembly and therefore has 
isolated the fault to this component. 

The PARI analysis was applied to a number of problems using a group of technicians who varied in skill level from 
novice to highly expert. Two types of information were obtained. First, the nature of expert/novice differences became 
apparent, enabling a definition of the most critical skills to be addressed in die tutoring system 12]. The second outcome 
was to obtain a very clear sense of the types of troubleshooting interactions that a technician uses to solve a problem. 

The Nature of Troubleshooting Skill 

The following is a brief summary of important skills identified through die PARI cognitive task analysis. 

Attendance to Physical Clues. As previously mentioned, overt problem symptoms, observable at die level of the overall 
behavior of the aircraft, provide a significant amount information to hydraulics technicians. 

Presence of Mental Models. Expert technicians have explicit mental models of aircraft system operation which they use 
to direct their troubleshooting behavior. These models tend to be accurate representations of the system, including How 
of control between components and between power systems and the operation of components within die system. However, 
because flighdine troubleshooting entails diagnosis and replacement, not repair, even expert technicians may not 
understand the internal workings of replaceable components. Experts are able to evaluate results of troubleshooting actions 
in terms of this system model mid make determinations of the integrity of different parts of the aircraft. Novices are able 
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to access* at best, severely impoverished mental models, and, therefore, had no basis for troubleshooting decisions. 

Procedural Expertise. Every component can be acted on with a variety of procedures; experts „jc particularly adept at 
disabling aircraft systems, thereby determining that large portions of the problem area arc functional or problematic. 
Novices are generally limited to removing and replacing components or following the procedures specified in the Fault 
Isolation Guide. 

Functional Classification. Experts generally have a hierarchically organized understanding of the functional characteristics 
of classes of components beyond the specific instances occurring on the F- 15. This ability to identify the shared and 
discrete characteristics of components also extends to the overall function of different hydraulic systems. 

Knowledge of Failure Characteristics. Experts use their knowledge of failure characteristics to isolate the problem to a 
particular power system or component type. 

Flexibility in Strategy Selection. Experts exhibit a great deal of variation in their problem solutions. Eor. numerous 
legitimate reasons, individuals may choose to approach a problem in different ways. Most strategics, however, involve 
space splitting of some sort. Experts usually attempt to isolate the problem to a particular power system first, then work 
within that power system. A frequent exception to this general rule is when an exceptionally cheap action is available 
that will provide some information about the system. 

Cost/Benefit Awareness. Experts try to use strategies that maximize information gained while minimizing cost. As a rule, 
they use space splitting strategies that attempt to rule out large sections of the problem area through application of 
relatively inexpensive procedures, where cost is directly proportional to the amount of time required to execute the 
procedure. The ability to balance cost and information is one of the hallmarks of expertise in this domain. A novice's 
strategic repertoire is frequently limited to removing and replacing components; for him, cost is not a consideration. 

Use of Consultation. Because of the complexity and intcr-relatedncss of die aircraft's systems, technicians from different 
specialties need to work together to solve a problem. Therefore, the hydraulics technician needs to know when other 
expertise is required and how to integrate information gained from such consultation into his mental model. 
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Troubleshooting Interactions 

The PARI analysis also highlighted the types of troubleshooting actions engaged in by a technician during problem 
solving. Many of these actions are evident in the example and i.iclude: 



Reading gauges and indicators 
vSctting switches and controls 
Initiating dynamic tests (moving controls) 
Observing the operation of components 
Powering the aircraft or subsystems of the aircraft 
Testing electrical and mechanical function 
Removing and replacing components 
Disabling subsystems of the aircraft 

Requesting assistance from colleagues with other aircraft responsibilities 
Tlie interface wits designed with this set of interactions in mind. 
HYDRIVE'S MTERFACE 

The challenge presented in the design and implementation of the HYDRIVE tutor was to build an interface informed by 
and consistent with the findings of the cognitive task analysis. 'Hie interface would be supported by the standard models: 
the system model representing domain knowledge, the student model representing an estimate of what the student knows 
or doesn't know and an instructional model to provide coaching in the domain as guided by the student model. Using 
the data incorporated into these models, HYDRIVE's interface would not only have to present a faithful rendering of the 
conditions, operations and interactions of the flighthne hydraulics maintenance job, but would also have to define and 
facilitate acquisition of effective troubleshooting skills without guiding the student to a degree that compromised the 
assessment, and Uius the instructional, functions. 

HYDRIVE' s interface uses video scenarios of dramatized flightlinc situations to present its problem set to die student. 
In, for example, the rudder deflection problem, die student witnesses a conversation between the pilot in the aircraft just 
prior to take off and the hydraulics technician who is with the pilot on the flightlinc. Air Eoree personnel were used for 
the filming and created the dialogue which explores the symptoms of the failure in characteristic terminology. 
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diagram* and vldao bar a 



information and Instruction* her* 



Figure 2. Interface screen layout 1 



Students can orient themselves visually outside the aircraft, then climb on boaid any area. They can locate and act on 
any system component and, through video, graphics and audio, see and hear what* s happening. They can start one or 
both engines, shut them down or hook up alternate power sources and test equipment. They can read gauges and 
indicators, set switches, and initiate aircraft operations. They can call on other technical specialists to perform tests and 
provide results. Until the problem is solved, all aircraft system behavior presents appropriate manifestations of the fault; 
after the problem is solved, the aircraft operations return to normal. At all times during tbe troubleshooting process, 
students have on-line access to the technical materials they customarily use, including fault isolation guides, system 
descriptions and schematic diagrams. 



1 lYDRIVF/s interface design originally incorporated the premise that the student's primary troubleshooting methodology 
was reducible to the performance of a series of actions on a series of components: he reads a gauge (visual inspection), 
flips a switch (set), moves the control stick (manipulate), has the electrician do an electrical test (electrical inspection). 
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The consequences of this premise produced the following student/interface interaction: 

1) student locates component to act on (e.g., student locates control stick) 

2) student chooses action (e.g., student moves control stick left and right) 

This pairing of locate component/act on component repeats (with necessary diversions into instruction, technical 
documentation and help) until th • problem is solved and is accomplished through the interface as follows: 

1) the student begins from the outside of die F-15 by clicking on one of several external aircraft video shots (top, 
bottom, left, right, Cockpit views); 

2) if an area oilier than the cockpit is chosen, the student is sent to a component location guide to find die desired 
component; 

3) when selection is accomplished, a video of the component appears with its list of possible actions; 

4) the student selects an action (which may or may not cause a change in die state of the aircraft) and is returned 
tt» the exterior aircraft shots to locate the next component; 

M the student can click on the Cockpit to see video of five interior views of die cockpit; 

6) clicking or. one interior view gets a menu of components in that area; 

7) when a component is selected, a video shot appears along widi the action menu; 

8) selection of an action (for example, manipulating the control stick) causes an appropriate video to appear; 

9) at diis point die student can exit to die exterior shots of the aircraft and begin another locate component/act on 
component sequence. 

LEVEL 2 COGNITIVE TASK ANALYSIS - STRUCTURE OF THE INTERFACE 

The preliminary interface described above was successful in accomplishing many important design goals, i.e., permitting 
die user to engage in troubleshooting actions important to the actual job. However, die initial design suffered from a lack 
of detailed cognitive analysis of die relation of user goals to die procedures required by die interface. With die urging 
and guidance of David Kieras, a GOMS (Goals, Operators, Methods, .Selection rules) interface analysis |1,3] wits 
conducted using die PARI data illustrated above. 

GOMS analysis is a practical mediodology diat seeks to supply a model of how a user employs interface functions to 
accomplish cognitive goals. 'llie model can dien be studied to see how die interface functions, or die sequencing of 
functions, promote or impede die user's performance of die target task. A GOMS model petitions task performance into 
four components. Goals are cognitive (not observable) and represent die objective of die user; they can be divided into 
a hierarchical and/or linear series of subgoals. A high level goal in hydraulics troubleshooting would be to determine if 
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the flight control system were operating correctly. Operators are physical (observable) and arc defined by the functions 
available through the interface. In other words, every time the user does something, s/lk is employing an operator. 
Manipulation of the control stick would be considered an operator. A method is a set of operators organized to 
accomplish a specific goal (or subgoal). For example, to determine whether the hydraulic system is working (goal), the 
user might employ the method of checking for warning lights in the cockpit, which would involve using the operators 
of turning on power and checking various indicating systems in the cockpit. Selection rules are used by an individual to 
select a method from multiple candidates. 

The (iOMS analysis presented below can be mapped to Steps 1 and 2 of {he PARI example previously presented, but 
is representative of troubleshooting behavior in genera!. The analysis revealed a functional pairing of operations at a 
higher level than choose component/choose action: supply input/observe output. Because input is generally activate ! 
through one component (e.g., the control stick), mid output observed through another (e.g., the rudders), and because une 
input can be linked to multiple outputs (e.g., the ailerons and stabilators as well), it becomes clear that the interface must 
provide simultaneous access to the input and output components. A GOMS analysis of a portion of a troubleshooting 
sequence illustrates this need. 

The first method presented is a high-level generic sequence: 

Method for accomplishing goa^ of troubleshooting problem 
Step /. Enter troubleshooting mode 

User sees: HYDRIVE troubleshooting menu 
Step 2. Think of something-to-do 
Step 3. Accomplish goal of doing something-to-do 
Step 4. If problem solved, return with goal accomplished 
Step 5. Go to 2. 

Somcthing-to-do represents a range of methods which can be defined by the application of a limited set of selection rules. 
The user can consult technical materials (TO's), can directly test a single component (e.g., is a leak observable?), or can 
evaluate the output of one component based on input to another (e.g., move control stick and observe rudder movement). 

Selection h'de set for accomplishing goal of doing somcthing-to-do 
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If something-to-do is consult TO's (technical documentation), 

then accomplish goal of consulting TO 
If something-to-do is running a single-component test, 

then accompli^} goal of running a single-component test 
If something-to-do is running an input-output test, 

then accomplish goal of running an input-output test 

Accomplishing the first two something-to-do' s was easily handled through the preliminary ititerface. However, an 
analysis of the input-output test method revealed that the preliminary interface was less than optimal. 'Hie GOMS 
analysis reveals the complexity of the input-output test. 

First, the user must define input(s) to the system. 

Method for accomplishing goal of running an input-output test 
Step I. Accomplish goal of supply the inputs 
Display is now of input component and input selection options 

Method for accomplishing goal of supply inputs 
Step AL Get the next component input to supply 

Step A2. Decide: If no more inputs to supply, then return with goal accomplished 
Step A3. Accomplish goal of supply an input to a component 

Method for accomplishing goal of supply an input to a component 
Step Ala. Find the input component 
Step Ala. Select the input component 
Step A3a. Select the input action 
Step A4a. Return with goal accomplished 
Step A4. Go to A I 

Once the user has defined inputs, the user has to decide what output(s) will be observed. Hie option is left up to the user 
for pedagogical reasons. l ; rom one input, however, we sec that it is important to permit multiple output observations. 
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Step 2. Decide: If observe outputs, then accomplish goal of observe outputs 
Display is now of output component and output selection options 
Method for accomplishing goal of observe outputs 
Step BI. Get the next component output to observe 

Step B2. Decide: If no more outputs to observe, return with goal accomplished 
Step B3. Accomplish goal of observe the output of the component 
Assuming that display returns to input display to maintain context 

Method for accomplishing goal of observe an output of a component 
Step Bla. Find the output component 
Step Bla. Select the output component 
Step B3a. Note the behavior of the component output 
Step B4a. Return with goal accomplished 
StepB4. Go to Bl 

Because it makes sense to allow multiple observations based on a single input, it becomes important to allow the user 
to stop the input in a straightforward manner. Without that ability, the flight controls will continue to move even after 
the user has decided to shift attention to another set of input/output components. 

Step 3. Stop the input. (/:.#., control stick has been left moving while rudder is observed, so it should be 
stopped.) 

Step 4. Return with goal accomplished. 

A primary revelation from the GOMS analysis was that although each clement in the input/output pair may involve 
multiple components, the physical focal point of this type of activity is the cockpit. This means Unit the student must 
be able to remain in the cockpit during the entire process of supplying input to the aircraft and be returned there 
automatically after each output observation. Until the student chooses to stop the action of the aircraft (eg M choose the 
Stop action for the control stick), every time s/he returns to the cockpit, the video of the control stick shows continuing 
motion. 
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The final implementation of the interface took this analysis into account. The interaction of student and interface, for 
the purpose of choosing components to act on when troubleshooting, now flows as follows: 

1) student clicks on one of two parts of a split video shot which divides the aircraft into Cockpit and Oilier (a click 
on Other takes the student to a component location guide where component selection and action selection proceed as 
before); 

2) if Cockpit chosen, then video of five different views of the Cockpit appears; 

?) student clicks on one cockpit view and a list of components in that area appears, each with a representation of 
\is current state in the aircraft, if applicable (eg., gauge values, indicators lit or unlit); 

4) student clicks on component and gets action menu with video of component in current suite (eg., control stick not 
moving. Haps switch set to Down); 

5) student chooses action and again gets appropriate video (if control stick manipulated, then motion shot of control 
slick/; 

6) at any time student can click on an Observe button which takes the student out of the cockpit to a component 
location guide where a componcnt(s) can be selected for observation; 

7) screens displaying components outside the cockpit contain a Cockpit button <o the student can toggle back and 
fotih between the cockpit and other areas of the aircraft at will. 

CONCLUSION 

The Level 2 GOMS analysis was able to draw on and extend the PARI Level 1 analysis to contribute to the interface 
design. Hie GOMS analysis provided a useful evaluation of a preliminary interface based only on the Level I analysis. 
Modifications, then, entailed design changes to flow of control within the interface rather than to actual screen content 
and basic function (witli some minor exceptions), lliese changes have produced an interface with a high degree of fidelity 
to the technician's working experience. Therefore, the results of this experience, so far, argue for die wisdom of interface 
design review, using a (K)MS model (or other methodology which deploys interface means to serve cognitive ends), at 
a point in die development process where interface functions (operators) have been sufficiently defined to allow for a 
detailed 'walk through' of sample problems. More complete data relating to the interface will be available only after 
1IYDR1VK is field tested (some time in the next few months). An analysis of those results, however, must he careful to 
separate the pedagogical and assessment issues Iro n those involving interface design alone. 



NOTES 

] HYDRIVE's interface makes extensive use of graphics and colors which arc not easily reproduced in this paper form. 
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